Using “Wait for Quiet” voting in The DAO
BACKGROUND A week or so ago, I outlined some key issue’s with The DAO’s voting system and suggested the first proposal passed should implement some simple fixes I described. A couple of days ago my friend Vlad Zamfir, a Curator, in collaboration with Emin Gun Sirer and Dino very sensibly published a similar request for a moratorium on whitelisting proposals to The DAO discussing these issues and describing new vulnerabilities, for example in regard to how The DAO’s splitting functionality might be abused by adversaries. Recently Gustav Simonsson a friend, a colleague at String, an Ethereum core dev and another Curator has indicated his support for this moratorium. We should be thankful for their efforts. Luckily many issues can be fixed quite trivially: for example, we can mostly address the “yes bias” in the voting system by requiring a quorum of “yes” votes rather than a quorum of (“yes”+“no”) votes. However a more tricky issue of technical interest concerns The DAO’s token holders being ambushed in the dying moments of debating by an adversary who suddenly submits enough votes to swing the result while denying others the chance to respond. Here I introduce a new solution to that problem that is arguably superior to the Double Tap solution I previously offered. My own interest in DAOs results from being cofounder of a venture-backed startup called String developing open chain finance DAOs for Ethereum.
RECAP OF VULNERABILITY To pass a proposal at the end of the “debating period” The DAO requires that some minimum number of votes — known as a quorum — has been received. Christoph Jentzsch, a great engineer and The DAO’s main architect, recognized that in practice most token holders won’t vote without a clear imperative and required commensurately low quorums. For example, votes from only 26.4% of tokens are needed to adopt a proposal that pays out $25MM, which might be thus passed with “yes” votes from only 13.3% of tokens (see my original post for more color on this). Low quorums introduce a very real danger however. For example, imagine a controversial and obviously bad proposal to pay out $25MM had been submitted that was comfortably losing as debating closed with 25% of tokens having voted in the proportion 43% “yes” and 57% “no”. The silent majority of token holders against the proposal would not bother voting as it would appear certain to fail. Yet they would be unaware of a group holding 4% of tokens, say, that directly benefited from the proposal and wished to push it through. This group could effectively ambush The DAO by submitting “yes” votes in the dying moments of the debating period to change the balance to 51% “yes” and 49% “no” denying the silent majority the chance to respond. Unless you think The DAO being gamed is fair game, such ambush voting needs to be prevented.
FUNDAMENTAL PROBLEM The scenario described results from a simple failure to collect sufficient information. In the example given the wisdom of the crowd strongly rejects the proposal but the system allows the majority to be ambushed and the proposal pushed through without their opposing voice being heard.
TRADITIONAL REMEDIES The need to collect full information is a common problem that society has addressed many times in the past. For example, court cases can be appealed and auctioneers wait for bids to fall quiet. In the case of traditional auctions each time a new bids arrives the auctioneer says something like “yes this is a wonderful item, going for $_, will anybody better that, this is a once in a lifetime opportunity, ok, going, going, gone” at which point he bangs the gavel to decide the result. Here whenever a new highest bid is made, the auctioneer provides others with the chance to make their own higher bid in light of the market demand now revealed (which indicates the item is more valuable). Buyers would feel it very unfair if another could win by submitting a bid at the last moment before the gavel fell. We can easily apply similar principles in The DAO.
DOUBLE TAP VOTING My original proposal for “Double Tap” voting was derived from how these things are traditionally solved. The proposal was that the initial debating period would be followed by some number of much shorter periods roughly analogous to the “going” in “going, going, gone!”. The idea was that after main debating period showed some decision (either “yes” or “no”) there would be a following period while votes continued to be collected. If the decision showing remained the same at the end of the following period then it would be decided, with the condition generally that a result must persevere for two consecutive periods to be decided. In practice the debating period would mostly be followed by a single “going” period and the decision decided there and then. Where results switch back and forth over successive periods, for example because some felt ambushed or the proposal were controversial, the process would always decide eventually because tokens can only be used to vote once (with any failure to win “yes” in two consecutive rounds interpreted as a de facto “no”).
However Double Tap is far from perfect. Those currently creating user interfaces for The DAO would have to get their thinking caps on about how to reflect this new process in an intuitive way and the ambush problem remains (albeit mostly mitigated overall) at the end of individual periods.
WAIT FOR QUIET VOTING A better system might somehow simply extend the debating period as appropriate to allow more information to be collected. User interface designers could then display the balance of votes and debating time remaining as currently, with the small difference that time remaining can be extended by the system. Wait For Quiet voting takes such an approach by calculating a “noise level” from voting and deciding the proposal only when the noise level has fallen sufficiently — applying the thinking that quiet signifies everyone has had their say.
POTENTIAL ADVANTAGES Before examining the specifics of how this might work, we can see that ambushes would be made difficult: any submission of votes at the last moment would increase the noise level and extend debating to allow a final decision to be fairly thrashed out. Furthermore, we can see that this system might allow us to use much smaller quorums securely as the silent majority of token holders could be sure of joining the debate if and when a bad decision looked likely to pass. In practice therefore, a much smaller group of thought leaders in The DAO’s community might be allowed to decide most decisions — which is desirable if they are willing to properly research proposals — with noise only increasing and extending debating when controversy occurs.
ORIGINAL IDEA The “Wait for Quiet” concept was developed after Vitalik casually proposed an idea in a conversation about Double Tap. His idea was that whenever a vote is submitted, the length t of the debating period might be increased by T/V where T is the default length of the debating period and V is the total number of tokens in circulation (i.e. the maximum number of votes that might be made). Whenever v new votes are submitted therefore The DAO would simply extend the debating period to t = t + v*T/V (and trivially even if every possible vote were made the debating period would only extend to length 2T = T + V*T/V). This simple system can be implemented in a single line of code!
This approach is however a little too simple for a bunch of reasons:
- Voting extends the debating period even when there is plenty of time remaining
- Voting extends the debating period even when voters are showing agreement
- Voting does not extend the debating period more when voters disagree, even if the voting balance is swinging one way then the other
“Wait For Quiet” addresses these issues by thinking about “noise levels” rather than passage of time per se. The system considers that each individual vote generates some additional amount of noise related to the overall balance of votes but that the resulting overall noise level decays. After the default debating period ends the system waits to decide the result until noise levels are sufficiently low (i.e. there is sufficient “quiet”) which is taken to signify everyone has had their say. This is also easy to implement as it turns out.
PROPOSED IMPLEMENTATION Since a user might split their votes among accounts, or submit them at different times, the logic must treat votes as though they were individually made or risk creating games around thresholds. That is, our design must treat votes atomically, such that when v votes in favor of some decision are submitted together the result is no different than if they had been submitted individually in sequence. Furthermore, we cannot care which accounts submit votes since this information is meaningless. Finally, our implementation should incentivize those who would otherwise to try and ambush others to instead submit their votes early: after all, we wish to decide proposals as fast as possible. The following equations are provided in their simplest form to illustrate principle, with optimizations suggested at the end.
We begin by defining that submission of a vote that makes the totals of “yes” and “no” votes equal generates a quantity of noise N. Otherwise we say the noise generated by some vote is inversely proportional to the number of votes e that must thereafter need to be submitted (of whichever type necessary) to create a 50–50 equilibrium (since in practice users submit multiple votes at once and we would calculate their net effect using a summation equation). Submission of a single new vote therefore increases noise as follows:
n = n + N/e
When the first call is made to the system in any block after the default debating period has expired — to submit a vote, ask for proposal execution or whatever —we test the noise level n. If the level n is below some minimum level Q that signifies quiet, then the proposal is executed.
if n < Q then execute()
Otherwise, the system has the current noise level decay by some special proportion D (repeat for each preceding interval since the last call)
n = n - n/D
Thereafter new votes increase the noise level again as specified.
ANALYSIS OF FUNDAMENTALS We can see that this mechanism provides multiple desirable properties:
- The further from a 50–50 tie we are the less noise votes make allowing for uncontroversial proposals to be decided faster
- Voting “against the grain” produces more noise (since the distance e shortens) providing relatively more debating time when significant opposition appears
- Ambush attacks are prevented since submission of votes always generates noise, with more noise generated the more controversial a proposal (as e will be smaller)
- Those who might have planned to push through proposals by ambush are instead incentivized to vote immediately further helping to expedite decisions (to see why imagine instead such an actor submitted their votes one by one, and each were followed by an opposing opposite vote. Since the e values would be smaller this would create more noise providing extra time for the silent majority to join the fray against them)
Finally we should note our system does not allow token holders to submit small numbers of votes each block to extend voting indefinitely as an attack. This is because a small number of votes can only significantly increase the noise level when voting is near tied, in which case it is beneficial that more time be provided to decide the outcome . Otherwise such votes will not be sufficient to overcome the decay in overall noise levels and quiet will still be quickly reached.
OPTIMIZATIONS Analysis of the fundamentals shows that the core mechanism provides the properties desired but some thought is required to choose suitable values for coefficients T, V, N and Q. Furthermore the core system needs some add-ons for example to bound the maximum noise level M that might be reached e.g:
n += N/e
n = min(M, n)
We will also wish to, for example, adjust the noise generated by each vote so that it drops less dramatically with e, e.g:
n += N/(V/100 + e)
That’s it from me :) Please let me know if you see problems!!
